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PREFACE 

Modern software engineering promises significant 
reductions in software costs and improvements in 
software quality. The Ada language is the focus 
for these software methodology and tool improve- 
ments. The community may have underestimated the 
preparation for Ada, including compiler development 
and education. More must be done. On the other 
hand, the community may have underestimated the 
benefits of Ada productivity and quality. Perhaps 

expectations should be raised. 

Software Engineering and Ada for Design over- 
views the IBM FSD Software Factory approach, In- 
cluding the software engineering practices that 
guide the systematic design and development of 
software products and the management of the soft- 
ware process. The revised Ada design language 

adaptation Is revealed. This four level design 
methodology Is detailed -- Including the purpose of 
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each level, the management strategy that integrates 
the software design activity with program mile- 
stones, and the technical strategy that naps toe 
Ada constructs to each level of design, A complete 
description of each design level Is provided along 
with specific design language recording guidelines 
for each level . 

Finally, some testimony is offered on education, 
tools, architecture, and metrics resulting from 
project use of the four level Ada design language 
adaptation . 

Section 1 

INTRODUCTION 

Software may be throttling the industrial devel- 
opment of the United States. As the inform* tun 
society takes hold, the demands for software are 
increasing. Furthermore, public expectation u 
increasing too; people want software trat pruv u- , 
the right answers on time, everytime, and does 
in a user-fr iendly manner. Software is intended to 
provide for the harmonious cooperation among people 
and machines. People possess an infinite variety 
and machines do only what is instructed, notwitn- 
standing the promise of artificial intelligence. 
As a result, the burden on software is substantial 
indeed and is increasing. 

Recently, software engineering has provided for 
the systematic design and development of soft-are 
products and the management of the software - 
ess. The result should be quality soft-are 
ucts obtained through design, sustained tnrunjn 
development , and monitored through technical re- 
views. We have always known that good projects are 
ones with few errors at the end. We now know mat 
good projects are also ones with few errors at the 
beginning. What may be needed now is a refinement 
of these methods, especially in the requirements 
and specification areas, their broad application, 
and preparation of adequate tools that re-cnfcrce 
and enforce their use while assisting in productiv- 
ity gains. 

Section 2 

SOFTWARE ENGINEERING FACTORY 

Software engineering provides for the systematic 
design and development of software products and the 
management of the software process. Software 
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engineering may be viewed In the form of a state 
machine composed of Inputs, transitions, outputs, 
and retained data (Figure 2-1). 

The Inpu.ts to the process include the qualified 
people* labor saving tools, and practical technolo- 
gy needed to apply modern design, development, and 
management practices In the production of usable 
and reusable software products of sufficiently high 
quality to ensure life cycle benefits and confident 
customer ownership. People today are required to 
be highly qualified and equipped with specialized 
training In both software technology and applica- 
tions. Testimony from early Ada users Indicates 
that the training needs may be substantial. Harlan 
Mills observed that as we shape our tools, our 
tools may later shape us. Tools represent an 
Instl tutlonallzed expert system, knowledge base of 
software methodology and style. Tool Investments 
often lag behind their need. Practical technology 
requires the application of basic principles from 
advanced technologies repackaged Into Intuitive 
approaches and simplified for use by Industry 
prac tl tioners and acceptance by customers. Tech- 
nology must employ an unders tandabl e conceptual 
model to assist the transition from user need to 
usable product. 

The transitions of the software engineering 
state machine are governed by the software engi- 
neering practices for design, development, and 
management, applying across the full life cycle. 
Software design includes methods for producing and 


verifying modular designs and structured programs. 
Designs are recorded using a design language based 
on Ada, Including both procedural designs and data 
designs. Advanced design ensures semantic corre- 
spondence of specifications through data dictionar- 
ies. Systematic design provides for functional 
allocation and decomposition of procedures and 
data. Systematic programming includes the elabora- 
tion of program designs using stepwise refinement, 
program design language, and correctness tech- 
niques, Taxonomy Includes a proper program with a 
single entry and single exit, a prime program 
composed of zero or one predicate constructs, inner 
syntax of data refinement and operations and tests. 
The Ada based design language used to record de- 
signs assists the reasoning of the designer and his 
communication with others In getting the design 
right, knowing it, and convincing others. Software 
development Includes the methodology for the early 
Implementation and Integration of detailed designs 
Into product Increments represented as source code 
libraries, conf iguration controlled through library 
hierarchies. In addition to Increnental releases, 
the concepts of rapid prototyping, software first, 
and component reuse are being refined for routine 
use on projects in the future. Software management 
assures the effe tive application of qualified 
people within a predictable process to originate a 
quality product that satisfies performance require- 
ments on schedule within cost. The use of Software 
Development Plans and technical reviews ensure an 
accurate view of status. 


THE SOFTWARE FACTORY 


INPUTS PROCESS OUTPUTS 



Figure 2-1. Software Factory 
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The outputs of the process include usable prod- 
ucts of high quality that may be reusable capable 
of assuring confident customer ovmershlp. Usable 
products are those that operate harmoniously within 
the user organization. They are adaptable to new 
requirements and feature userfrlendly interfaces. 
The reward for this may be friendly users. Quality 
products are those that have few errors at the end. 
These are the same ones that have few errors at the 
beginning. A reusable product Is one that contin- 
ues to meet changing requirements through product 
enhancements. Futhermore, reusable products are 
transportable to other systens for similar uses. 
The Ma language promises to provide for software 
reusability. Using artificial Intel 1 Igence, a 
components library of specifications can be Inter- 
rogated for software components needed for new 
applications. As the industry becomes skillful and 
expert at matching existing products with new 
needs, the software factory may become a reality. 

Section 3 

SYSTEMATIC USE OF ADA AS A DESIGN LANGUAGE 

Flirting with Ada? Careful. She Is more than a 
programming language but less than a compiler for 
many. In Mega trends . John Naisbltt points out that 
trends are - n ke horses . If you want to ride them. 
It pays to go In the same direction the horse is 
already traveling. He also points out that fads 
originate at the top, tend to peak, and then fade 
out. On the other hand, trends are bottom up, 
possess broader support, and persist. 

The use of Ada as a programming language may 
correspond to Naisbitt's charac teri za t ion of a fad, 
top down, perhaps explaining its sluggish begin- 
ning. For Ada the programming language, this is 
the awkward period between promise and del ivery. 
On other hand, the use of Ada as a design language 
may be a trend, arising from the bottom as a popu- 
lar choice. It is happening today. 

A design language may be used for a number of 
reasons. It provides the facility to record design 
decisions. Once recorded, these design decisions 
can be shared with others forming the communication 
baseline among system engineers, software engi- 
neers, and integration and test engineers. It 
provides the basis for the designer to be more 
convincing in the defense of his design. It pro- 
vides others with a rlear reference point to focus 
their criticisms. The result is a better design. 
The use of Ada as a design language encourages good 
software engineering while at the same time permit- 
ting the design to obtain rigor In syntax and 

semantics through the use of Ada compiler product 
tools. Ada as a design language provides a plat- 
form for sys tematlcal ly accomplishing rapid proto- 
typing through use of the emerging software design 
and product itself. In ways yet to unfold, Ada 
design language may also be a useful basis for 

assisting the access of reusable components. To be 
able to support these various uses systematically, 
Ada as a design language needs to be Integrated 

Into a software engineering methodology. 

3. 1 Four Level Design 

An Ada based software design methodology has 

been adapted from the software engineering prac- 


tices discussed in advanced design, systematic 
design, and systematic programming. This adapta- 
tion features four levels of design supported by a 
management strategy and a technical strategy. The 
management strategy maps the first two levels of 
design to the spec i f ica tlon process and its review 
and the last two levels of design to the detailed 
design process and Its review. The technical 
strategy purposefully and rigorously utilizes the 
expressive power of Ada at each level of design by 
mapping particular Ada constructs for use at each 
level . 

The purpose of each level of design (Figure 3-1) 
considers the expected audience hierarchy within a 
project, ranging from readers to writers and in- 
cluding programmers , engineers, and managers. 
Early design levels must be intuitively understand- 
able by all members of the audience and cannot 
depend on everyone being fully Ada literate. To 
support this need, Level 1 design is intended as 
the user contract. The user should be thought of 
as other software products that might utilize or 
Interface with the software being designed as 
opposed to the end user of the system. Le.el 2 
design portrays the design parts and their r>: ; - 
tlonships both data interfacing and tasking. 

3 design elaborates a detailed functional n.-M f 
that Is Independent of the target operating 
and instruction set architecture. Finally, « 

designs are detailed designs that are fully :.m. 
geted to the operating system and irs l r jl t . i - t 
archi tec ture , ready for impl enen ta t i on r on--, i , 

efficiency and capacity constraints. 

FOUR LEVEL DESIGN 


METHODOLOGY THAT RIGOROUSLY UTILIZES THE EXPRESS!', t 
POWER OF ADA PDL AT EACH LEVEL 

LEVEL 1 USER CONTRACT 

LEVEL 2 DESIGN PARTS AND RELATIONSHIP 

LEVEL 3 DETAILED FUNCTIONAL DESIGNS INDEPENDENT Of 

TARGET 

- OPERATING SYSTEM 

- INSTRUCTION SET ARCHITECTURE 

LEVEL 4 DETAILED DESIGNS FULLY TARGETED R E A D > f . ’ ” 

IMPLEMENTATION 

Figure 3-1. Four Level Design 
3.2 Management Strategy 

The management strategy for the four ' e > . ■ 
design approach (Figure 3-2) maps levels 1 and 2 t: 
the sped fication rev lew mi 1 estone and levels : 

4 to the design review milestone. The specif.:a- 
tlon review milestone equates to the Preliminary 
Design Review (PDR) , the design review milestone 
equates to the Critical Design Review (CDR). In 
the MiLSTD 2167 process level 1 and 2 designs are 
Included In the Software Top Level Design Document; 
level 3 and 4 designs are Included in the Software 
Detailed Design Document. 

Beginning with Level 1, the spec i f ica t Ion is 
Input to the software design process. A Level 1 
design Is produced and recorded in the form of an 
Ada Package Spec i f i c a t ion . The Level 1 design ani 
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Figure 3*2. Management Strategy 


any reuse candidates are subjected to a design 
review. The design review may be conducted elec- 
tronically* or it may be conducted through a meet- 
ing of team members. Participants are highly 
trained experts committed to reviewing the design 
for completeness, correctness, usability, perform- 
ance, and overall user satisfaction. Each reviewer 
must be personally satisfied with every aspect 
before the design review is concluded. The appli- 
cation of modern software engineering practices and 
their enforcement through a unanimous concensus of 
these highly trained experts is expected to provide 
a powerful impetus to dramatically improved product 
quality. 

Once the design is satisfactory , the metrics 
associated with the software engineering process 
and the software product are reviewed and expec- 
tations revised. For the software engineering 
process the metrics include productivity and quali- 
ty expectations. For the software product these 
metrics include complexity measures, reliability, 
and computer resource loading. these metrics are 
reviewed for compliance with budgets, perhaps 
necessitating adjustments In the design in an 
effort to achieve compliance. The specification 
itself may need to be reassessed and partitioned 


into essential requirements and desirable features. 
Certain desirable features may need to be elimi- 
nated or reduced In order to ccmply with management 
budgets . 

At Level 2, the design for each component part 
identified in level 1 Is recorded as an Ada package 
specification and Its body. The Level 2 Ada pack- 
age specification and body are evaluated for reuse 
candidates, continuing the systematic exploitation 
of reusability. The design review is conducted, as 
In level 1. Metrics data i S a *. ired and analysed 
for Level 2 with the design to cost procedure 
followed If necessary. The Software Top Level 
Design Document Is then subjected to th' Prelimi- 
nary Design Review (PDR), Throughout this process, 
systems engineers and software engineers work in a 
dependable relationship in shaping and fitting 
designs to meet user needs. 

At levels 3 and 4 f the design for each iden- 
tified subunit is recorded as an Ada procedure with 
its accompanying intended function commentary 
Procedure CALL semantics and intended function 
commentary are evaluated for reuse candidates, 
again continuing the systenatic exploitation of 
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reusability. Design reviews are conducted. Met- 
rics data Is analyzed. The design to cost proce- 
dure continues to operate but with diminished 
flexibility since the specification has been base- 
lined at PDR. 

3.3 Technical Strategy 

The Technical Strategy (Figure 3-3) governs the 
mapping of Ada constructs to each level. This 
mapping is Intended to follow the architectural 
line of the language. Futhermore, the construct 
mapping by level provides a natural partitioning 
suitable for educating both readers and writers a 
1 1 ttle at a time. 

Ada constructs are mapped to each level for 
outer and inner syntax. Outer syntax Includes 
organizing units and control structures, both 
sequential and asynchronous. The Inner syntax 

provides the format for expressing data and the 
operations and tests on the data. The constructs 
are assigned to each level with the objective of 
satisfying the purpose of that level. Once as- 
signed to a level, a construct Is permitted to be 
used in subsequent levels. 

The Mi. product form for Level l Is the package 
specification used to express the user contract. 
This calls for an organizing outer syntax along 
with inner syntax commentary. Level 1 Is limited 
to a few self evident constructs needed to accom- 
plish its purpose. Those constructs are listed in 
Figure 3-4. They can be conveniently organized 
into a package specification template used to 
govern the style of the design recording. Other 
design recording guidelines ray be set forth, 
including naming convention, commentary for in- 
tended functions, and key words in structured 
commentary useful in encouraging the use of the 
sta te machine model . 

The product form for Level 2 is the package 
speci f ica t ion and package body used to express the 
design parts and their relationship. This calls 
for an outer syntax of structuring and tasking 
constructs. The inner syntax may be expressed as 
Ada abstractions, including abstract data types. 


Procedural elaborations are not carried out in 
Level 2 but instead are permitted to appear as 
procedure calls. The additional Level 2 onst’urts 
are shovwi in Figure 3-4. Those too can be conven- 
iently organized into package specificjfioi <*nd 
package body templates used to govern the style of 
the design recording. Design recording guidelines 
of Level 1 may be expanded to include the abstract 
data types jiennisslble . 

The product form for Level 3 is the procedure 
elaboration used to express a detailed functional 
design. This calls for a full conplement of outer 
syntax function expressions and inner syntax data 
reflnenent, including predefined data types and Ada 
primitives. The additional Level 3 constructs are 
shown in Figure 3-4. Here too, procedures and task 
templates are used to guide the style of the design 
recording. Additional recording guidelines n ay be 
stated. Furthermore, to control the quantity of 
the Ada PDL being produced. Level 3 may be limited 
to the elaboration of only those procedures present 
In Level 2 as procedure calls. 

The product form for Level 4 is the procedure 
elaboration, as well as function elaborations used 
to express a fully targeted, detailed design, f jll 
MIL-STD 101 SA is available at Level 4 (see 1 ' , 
3-4). 

Section 4 

CONCLUSION 

Software E ngineering and Ada in Design is an 
earl y milestone report on the systematic use <j ' •! i 

as a design language. From this experience, it is 
clear that the preparation for the use of Ata nas 
been underest imated in several areas, includm; ;,Ja 
compiler acquisition, tool integration, and educa- 
tion. 

The Ada compiler acquisition difficulties in 
Industry are well known. The need for Ada products 
during the design activity has .eceived less atten- 
tion. It is nice to have an Ada front-end product 
for semantic and syntax analysis during le.els 1 


TECHNICAL STRATEGY 




OUTER 

INNER SYNTAX 


PURPOSE 

SYNTAX 

FUNCTION 

DATA 

LEVEL 1 

USER CONTRACT 

ORGANIZING 

COMMENTARY 

COMMENTARY 

LEVEL 2 

DESIGN PARTS AND 
RELATIONSHIPS 

STRUCTURING. 

TASKING 

PROCEDURE CALLS 

ABSTRACT DATA 
TYPES 

LEVEL 3 

DETAILED FUNCTIONAL 
DESIGNS INDEPENDENT 
OF TARGET 

— 

EXPRESSIONS 

PREDEFINED DATA 
TYPES. 

ADA PRIMITIVES 

LEVEL 4 

DETAILED DESIGNS 
FULLY TARGETED 

- 

REFINEMENT 

REFINEMENT 


Figure 3-3. Technical Strategy 
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ADA CONSTRUCTS 


Figure 3-4. 


Ada Constructs 


and 2. It is a nece.-ity to have this tool availa- 
ble and ready for use during levels 3 and 4. 
Without it, the reenforcement of Ada education 
through the design activity is lost. Furthermore, 
the error discovery opportunity is postponed to 
downstream. The design inspection accompanying 
each design level needs the output of the Ada 
front-end. Where rapid prototyping is intended, 
the Ada compiler itself is needed to permit code 
generation and execution. 


For early Ada projects, the education of the 
project team may need to be Integrated with the 

design activity. One approach to this is to train 
people in one design level at a time, fo’ lowed by 
the performance of the design activity and its 
review. In this way, the training schedule can be 
distributed throughout the performance period, the 
training for each level can be refined based on the 
results of the preceding design review, and project 
people new to Ada can progress through the experi- 
ence sharing problens and obtaining assistance 
within the team. In the four level design ap- 

proach, Level 1 represents only four constructs, 
all contained in a template. As a result, there is 
an early success for the new Ada PDL designer, 

level 2 adds more constructs and is ayain guided by 
templates, assisting success. Level 3, however, 
represents the first time the Ada POL designer must 
operate subs tan 1 1 al ly on his own with a large 

number of Ada constructs. At Level 3, design 
reviews may result in a substantial reworking of 
the design. By level 4, the Ada experience begins 
to pay off, and Ada POL designers are completing 
their designs with confidence. 


In formul a t ing arc h 1 tec tures for Ada software 
designs, new thinking may be needed. Important 


benefits are possible In Ada throuyh modern soft- 
ware engineering. To obtain these benefits, 
software designs must make the transition fron 
designs that simulate data flow to designs that 
encapsulate data in ways natural to the application 
providing only as much visibility as necessary ana 
as much information hiding as possible. Further- 
more, to obtain these benefits, the Ada tasking 
model needs to be exploited at appropriate levels 
in the design. The Interface with commercial 

software products needs to be accommodated in a *ay 
that retains the cost benefits of these products, 
but docs not dominate the software a rchi tec tu»*e . 
More work is needed in uniform design mnrpholo;ies 
for Ada to provide useful Ada archi f ec ture >-od e 1 s 
for early users, as well as the framework for 
exploiting reusable components by all users. 

Very little is known about Ada metrics. As a 
result, there are many questions about the sue of 
Ada programs and designs, Ada productivity, 
quality, and Ada performance. The early experience 
with Ada POL seems to show that a low rat to may 
exist between Ada source lines and Ada design 
lines. It may be 2:1 or 3:1. Where Ada is both 
the target language and the design language, the 
Ada POL is part of the product. In this case, 
Insight about the ratio may assist the allocation 
of effort and schedule between the design and code 
activities. The recent experience showed that the 
combined Level 1 and 2 ratio was about ?S:1, Level 
1-3 about 10:1. and Level 1-4 less than S:l. Not 
enough is known to use these results as management 
budgets. 

The revised I DM FSD four level Ada PDL meth- 
odology has demonstrated some important benefits in 
recent use (Figure 4-1). Expanding the audience of 
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BENEFITS: FOUR LEVEL ADA PDL METHODOLOGY 


• AUDIENCE - BOTH TECHNICAL AND NON TECHNICAL 

• PRODUCTIVITY - TEMPLATES AT LEVEL AND CONSTRUCT 


• QUALITY - MINIMUM CYCLOMATIC COMPLEXITY 

• PERFORMANCE - FOCUS ON TASKING AT LEVEL 2 


• PORTABILITY 


FULLY TARGET INDEPENDENT LEVEL 3 


• REUSABILITY 


LEVEL FORMAT PERMITS EFFECTIVE 
ACCESS FROM COMPONENTS LIBRARY 


» ADA TRAINING - LEARNING AND USING ADA, A LITTLE AT A 

TIME, IS AN EFFECTIVE APPROACH TO ADA 
TRAINING, ALONG ARCHITECTURE LINE 


• MAINTAINABILITY - FOUR LEVELS PROVIDE A STAGED, LAYERED 

INTRODUCTION TO DESIGN AND 
IMPLEMENTATION DETAILS 


• PREDICTABILITY - MEETING COST AND SCHEDULE AS ASSISTED 

BY DESIGN TO COST FEATURE OF 
MANAGEMENT APPROACH 


Figure 4-1. Benefits: Four Level Ada POL Methodology 


design reviewers from technical to non- techn ical 
permits useful and needed user input to the comple- 
tion of the specification and to early design 
decisions. This is made possible by a training 
program, patterned after the four levels, that 
teaches Ada a little at a time along the architec- 
tural line of the language. Furthermore, the 
templates that govern the product style at each 
level provide a crutch for the early Ada user both 
reader and writer, a boost to productivi ty , and the 
assurance of uniformity ir design style. Product- 
ivity may be given a more substantial boo*t when 
reuse of existing Ada components can be obtained. 
The Level 1 template format may assist this compo- 
nent reusability by providing the semantics needed 
to access a components library. Managing and 
meeting cost ar.d schedule budgets Is assisted by 
the systematic use of the design to cost feature 
embedded in each design level. Once completed, the 
four levels of Ada PDL provide the layered Intro- 


duction to design do tails needed by the maintain*" 
to learn design details as needed and to crijwuv 
any required product adaptations with confide' 
Designs produced with the four level Ada PDl met'- 
odoloqy tend lo be the simplified designs t'j' 
result from modern software engineering. At : - 
same tire these designs consider performance re- 
quirements and meeting real time deadlines u.r j. 
the tasking focus at Level L and through the met- 
rics at every level. Finally the nethodolo;.. 

supports portability through the Level 3 target 
independence of operating systeir and instruct v- - 
set arc hi t^c ture . 

Although true that the community has under- 
estimated the preparation for Ada, this prepara 
has been started and is underway. It may also be 
true that the cor.nuni ty has underestimated t f \> 
benefits of Ada which are substantial and are still 
being discovered. 
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